Today there is an increasing interest in data communications. In data communications, the data (e.g. application data) that is to be sent from a source to a recipient is often sent using a sequence of data blocks or packets. The data blocks that are not successfully received by the recipient may have to be retransmitted. To effect retransmissions, one or more receipt reports may be sent back to the source, in order to inform the source of the data blocks that need to be retransmitted. The receipt reports may in principle include two basic forms of information: acknowledgement (ACK) indicating that a particular data block has been successfully received; or negative acknowledgement (NACK) indicating that the particular data block has not been successfully received. Hereinafter, the term ACK/NACK information will be used for information that includes ACK and/or NACK information.
Data communications are becoming increasingly important also in wireless communications. For example, in the EDGE standard (Enhanced Data rates for GSM Evolution) there are several RLC (Radio Link Control) operation modes available for data transmission, for example: acknowledged mode; and un-acknowledged mode. In un-acknowledged mode, there are no retransmissions, and delays are therefore kept at a minimum. However, bandwidth is wasted since powerful channel coding must be used to guarantee an acceptable FER (Frame Erasure Rate)/BLER (BLock Error Rate). In acknowledged mode, data blocks are re-transmitted until successfully received, regardless of any delay requirements. Since the number of re-transmissions is unlimited, it is not possible to guarantee that an acknowledged mode bearer will keep any delay requirements. Also, the ACK/NACK information is sent in special messages that require one full radio block for transmission. In order to keep the transmission delays at a minimum, ACK/NACK information should ideally be requested immediately after each transmission. However, such a practice would cause unacceptable overhead, since receipt reporting would consume half of a used radio resource. Consequently, the ACK/NACK information protocol in EDGE is not designed for delay sensitive services. Overhead would be significant if ACK/NACK information messages would be sent after each transmission. Also, currently it is not possible to limit the number of re-transmissions, so the transmission delays may be very large, especially for low C/I values.
In 3GPP/GERAN, the Siemens company has made a proposal (see 3GPP TSG-GERAN Meeting #27 Tdoc GP-052634: ‘Fast Ack/Nack reporting’) for a protocol for receipt reporting for GERAN. The proposal basically defines a concept where a mobile station can send a short bitmap in an uplink radio block in response to a polling request from a radio access network. The polling request is also a synchronization event between the radio access network and mobile station, allowing a receiver in the radio access network to know which data blocks are covered by the short bitmap. The short bitmap contains ACK/NACK information relating to recently received data blocks. More precisely, if the polling request is received at a frame number x, the mobile station will send back the short bitmap indicating the status of all the data blocks received in all assigned timeslots during frames x, x-1, . . . , x-n, where n depends on a defined size of the short bitmap and the number of assigned timeslots.
There are, however, some drawbacks with the Simens proposal. The proposal is based on the polling requests from the radio access network, so ACK/NACK information is requested periodically, even if all data blocks have been successfully received by the recipient. This causes extra overhead, in particular, if there are few uplink transmissions. Furthermore, the proposal also suggests a particular form of channel coding that is not currently supported by all standards, e.g. the EDGE standard. The proposal is thus rather inflexible.
Consequently, there is a need for receipt reporting that is flexible and applicable to delay sensitive applications.